Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #358 +/- ##
==========================================
+ Coverage 78.19% 78.75% +0.56%
==========================================
Files 58 58
Lines 6690 6709 +19
Branches 630 632 +2
==========================================
+ Hits 5231 5284 +53
+ Misses 1459 1425 -34
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
d51c2b6 to
cf28439
Compare
godlygeek
changed the title
Prevent reading past the end of a truncated or malformed core file's `NT_FILE` note. Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
cf28439 to
11d9cb4
Compare
| // File names are stored at the end of the main table | ||
| const char* filename_table_start = ptr + count * entry_size; | ||
| const char* filename_table_ptr = filename_table_start; | ||
| const char* filename_table_ptr = ptr + count * entry_size; |
There was a problem hiding this comment.
nit: Consider renaming to filename_start, it will make later uses with filename_end cleaner.
There was a problem hiding this comment.
With one name, we have to choose which of two things to make clearer:
- That there is a table of file names which we are iterating through
- That our pointer points to the start of the current name cstring in that table
I think the rename you're suggesting makes the more obvious thing clearer, at the cost of obscuring the much less obvious and weirder thing - that we're iterating through N null-terminated strings all concatenated to each other.
How about calling our main iterator into the table next_file, and our pointer to the end of the first C string it points to next_file_end?
There was a problem hiding this comment.
Fair point.
I like "next" for kind of linked-list semantics. Would be nice to have "filename" instead of "file", and would be nice to have _start suffix on the first variable for symmetry with _end suffix, which I think does not affect the linked-list semantics.
My preference order would be:
- next_filename_start/next_filename_end
- next_filename/next_filename_end
- next_file_start/next_file_end
- next_file/next_file_end
|
OK, I've pushed a fixup commit that I believe addresses all of your concerns. If you're happy with the results, lmk and I'll squash and merge. |
This branch has not been deployed
3 participants
Prevent reading past the end of a truncated or malformed core file's
NT_FILEnote.